In integrated circuit (IC) designs, for example, registers are utilized to store information. Some integrated circuits or chips use special registers that are referred to as semaphore registers. These special registers or semaphore registers may be utilized for a plurality of different applications or operations. One application of semaphore registers may comprise the allocation of mutually exclusive accesses to hardware resources, for example, arithmetic units, communication ports, and memory units, that are generally shared among multiple software program tasks in a computerized system or among several processors. The software program tasks may be referred to as threads.
When debugging or verifying the operation of complex IC systems which use semaphore registers on a chip, it may be useful to have the capability to monitor the contents of the semaphore registers in order to track and identify which software thread is using a particular hardware resource. Such tracking provides verification that the software threads are accessing hardware resources in an efficient manner or in accordance with an appropriate protocol or schedule. Unfortunately, a complete set of semaphore registers will contain a large amount of data at any particular time, and it is difficult to make all that data observable on the pins of the chip in such a way that the contents of the registers can be monitored continuously and in real-time. In this context, real-time may refer to the fact that the chip may run at full speed without interruption, while the contents of its registers are being monitored.
A non-real-time solution would invoke stopping all normal activity on the chip and read all of the registers. This would provide a momentary snapshot of the contents, but it is not very useful because it does not provide the ability to monitor the contents continuously in real-time and at full speed. Continuous monitoring allows the IC system designer to verify that multi-threaded applications are running properly and efficiently under specified operating constraints. Another potential solution would be to attempt to monitor writes to the chip and try to deduce what is happening. However, since writes to semaphore registers generally operate independently, and in certain instances are ignored by the register hardware, knowing what was written to the chip does not necessarily indicate the resulting contents of the target register.
The exact implementation and behavior of semaphore registers may be system and/or application dependent. In general, semaphore registers are utilized to store an identifier or ID number of the software thread that is currently using the hardware resource. If the semaphore register value is logic 0 and the semaphore register default value or reset state is also logic 0, then the hardware resource that corresponds to that semaphore register is not in use. If the semaphore register value is not its default or reset value, then the semaphore register contains the ID number of the software thread that is using the hardware resource. A hardware resource can only be used by one thread at a time. In order to share a hardware resource among several software threads, a specific semaphore protocol may be defined to examine the contents of the semaphore register that corresponds to that hardware resource, to gain access to the hardware resource if available, and to subsequently release the hardware resource, for example. The semaphore protocol may also establish the reset state or default value of the semaphore registers.
FIG. 1 contains a flow chart showing a process that a software thread may use to share a hardware resource. Referring to FIG. 1, the flow chart 100 starts by determining in step 102 whether the hardware resource is needed by the software thread. If the hardware resource is not needed, then the software thread returns to step 102. Otherwise, the software thread proceeds to step 104 where it reads the contents of the semaphore register that corresponds to the hardware resource it needs to use. After reading the contents of the semaphore register, the software threads proceeds to step 106 where it determines whether the semaphore register is at logic 0. If the semaphore register value is not logic 0, then the hardware resource is in use and the software thread returns to step 104. If the semaphore register value is logic 0, then the hardware resource is available for use and the software thread can attempt to take ownership of the hardware resource and proceeds to step 108. In step 108 the software thread writes its ID number or identifier to the semaphore register and then proceeds to step 110. In step 110 the software thread reads the semaphore register value and proceeds to step 112. In step 112 the software thread determines whether the semaphore register value is its ID number or identifier. If the value read is not its ID number or identifier, then the software thread did not actually succeed in taking ownership of the hardware resource and returns to step 106. If the value read in step 110 is the ID number or identifier, then the software thread has successfully taken ownership of the hardware resource. If the hardware resource is in use by the software thread, then the software thread proceeds to step 114 where it determines whether it is done using the hardware resource. If it is not done, the software thread returns to step 114. If it is done using the hardware resource, then the software thread proceeds to step 116 where it writes the value logic 0 to the semaphore register that corresponds to the hardware resource. After writing to the semaphore register in step 116, the software thread returns to step 102.
Failure to gain ownership of a hardware resource that was available can happen if two software threads attempt to take ownership of the same hardware resource at about the same time. For example, assume that software thread 10 wants to use hardware resource AA. In this regard, software thread 10 reads the corresponding semaphore register AAreg for hardware resource AA to determine if the value is logic 0. If the hardware resource AA is in use, the value will not be 0, and the software thread 10 may poll the semaphore register, i.e. read it repeatedly, and wait for the value to read back a value of 0. When the value that is read is 0, it means the hardware resource is available and software thread 10 may attempt to take ownership. However, assume that software thread 20 was also polling semaphore register AAreg, and has also determined that the hardware resource AA is available and attempts to take ownership of hardware resource AA. Both software threads attempt to write to register AAreg. Software thread 10 writes a value of 10, and software thread 20 writes a value of 20 to semaphore register AAreg.
Depending on the system hardware, and the exact timing of the execution of the software threads, one of the write operations will happen before the other. For the purpose of this example, the write done by software thread 20 is assumed to occur first, followed immediately by the write done by software thread 10. When software thread 20's write occurs, the semaphore register value will change from 0 to 20. When the subsequent write done by software thread 10 occurs, the value of semaphore register AAreg does not change, and will retain the value of 20. This is the case because semaphore register protocol may require that the semaphore register value changes back to the reset state value before a new ID number or identifier can be written. This may require the use of specialized hardware. After both software threads do their writes, they each read the ID number or identifier stored in the semaphore register. It does not matter which read executes first. They will both read back a value of 20. Since the value matches the ID number of software thread 20, both software threads know that the hardware resource is now owned by software thread 20. Software thread 10 may not use the hardware resource, and may poll the semaphore register AAreg again to wait for hardware resource AA to once again become available. Software thread 20 may use hardware resource AA.
When software thread 20 is finished using hardware resource AA, it will write a value of 0 to semaphore register AAreg. Since software thread 10 has continued to poll semaphore register AAreg, it read a value of 0 and know that hardware resource AA is once again available. Software thread 10 can now write a 10 to the semaphore register, and then immediately read the semaphore register to check the value. This time, the value will be 10, and software thread 10 knows that it owns hardware resource AA. The process repeats as required. The process and behavioral concepts of the hardware may be the same independent of the number of resources and the number of threads attempting to simultaneously use them.
Further limitations and disadvantages of conventional and traditional approaches will become apparent to one of skill in the art, through comparison of such systems with some aspects of the present invention as set forth in the remainder of the present application with reference to the drawings.